Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Script Loading Strategy - ML2 #13 - Add get_eligible_loading_strategy method #35

Conversation

kt-12
Copy link

@kt-12 kt-12 commented Feb 23, 2023

Trac ticket:


This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

@kt-12 kt-12 changed the title Script Loading Strategy - ML2 issue 13 Script Loading Strategy - ML2 issue 13 add get_eligible_loading_strategy method Feb 24, 2023
@kt-12 kt-12 changed the base branch from enhancement/wp-script-api-milestone1 to enhancement/wp-script-api-milestone2 February 24, 2023 09:50
@kt-12 kt-12 changed the title Script Loading Strategy - ML2 issue 13 add get_eligible_loading_strategy method Script Loading Strategy - ML2 #13 - Add get_eligible_loading_strategy method Feb 24, 2023
Copy link
Collaborator

@joemcgill joemcgill left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leaving feedback (mostly formatting related).

As a process note, I'm find it a bit difficult to follow the way you have PRs set up to merge into milestone branches before merging to the main feature branch. Given that this is meant to be a continuation from #34, I'd love to see us get that merged into the base feature branch you've set up and then set each of these M2 branches to merge into the main feature branch, rather than waiting for all of it to land "at once" as part of a milestone. That way, we're also getting the benefit of seeing the test coverage increase over time, with each PR and will more likely avoid merge conflicts at the end.

src/wp-includes/class-wp-scripts.php Outdated Show resolved Hide resolved
src/wp-includes/class-wp-scripts.php Outdated Show resolved Hide resolved
src/wp-includes/class-wp-scripts.php Show resolved Hide resolved
src/wp-includes/class-wp-scripts.php Outdated Show resolved Hide resolved
src/wp-includes/class-wp-scripts.php Outdated Show resolved Hide resolved
src/wp-includes/class-wp-scripts.php Outdated Show resolved Hide resolved
}

// Handling async strategy scenarios.
if ( empty( $this->registered[ $handle ]->deps ) && empty( $this->get_dependents( $handle ) ) ) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd love to see some more test cases set up to confirm that each scenario you're accounting for in this logic tree is working as expected.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@joemcgill Test cases are the main reason I had to set a base milestone branch. The way our milestone tasks are, we normally have to get to the last task to test out all the other prior tasks in the milestone.

In milestone 2, get_eligible_strategy can only be tested via do_item method ( #38 ) which is a part of different task in same milestone. In milestone 2 all test cases are in PR #38.

Just to be certain that everything in a single milestone works as intended before it goes to the base branch, i created a separate milestone base branch.

Base automatically changed from enhancement/wp-script-api-milestone2 to enhancement/wp-script-api-strategy-base February 25, 2023 01:46
@kt-12 kt-12 added the needs:code-review This requires code review. label Feb 27, 2023
src/wp-includes/class-wp-scripts.php Outdated Show resolved Hide resolved
src/wp-includes/class-wp-scripts.php Show resolved Hide resolved
src/wp-includes/class-wp-scripts.php Outdated Show resolved Hide resolved
src/wp-includes/class-wp-scripts.php Outdated Show resolved Hide resolved
src/wp-includes/class-wp-scripts.php Outdated Show resolved Hide resolved
src/wp-includes/class-wp-scripts.php Outdated Show resolved Hide resolved
src/wp-includes/class-wp-scripts.php Outdated Show resolved Hide resolved
return 'async';
}

// Handling defer strategy scenarios. Dependency will never be set async. So only checking dependent.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kt-12 Do we need to mention Dependency will never be set async. So only checking dependent. here? I am not following what this means, did you mean to state that dependencies will never be deferred so you're only checking dependents?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@10upsimon So, per the rules, defer can only have 'defer' or 'blocking' dependencies; it can never be 'async'. ( point 1 )

A decision that a script is to be set to async, defer, or nothing is made by get_eligible_loading_strategy.

But, if you check the rules for async in this function, a script with dependent will never be set async. ( point 2 ).

From points 1 and 2, I can say if the current script has some dependency, the dependency script will never have async strategy (as it has a dependent). So we can avoid a recursion check to find strategy in dependencies.

I hope I still don't sound confusing.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@10upsimon I have removed the extra text here.

@10upsimon
Copy link

For visibility sake, as I myself wondered where the unit tests were that handled the various loading strategies, they've been added to the PR for #14 and can be seen at https://github.com/10up/wordpress-develop/pull/38/files#diff-09a2e7959959d6a08ef07b1849e0178b853f7ef86f7885bbf9be2ed261145b24

kt-12 and others added 7 commits February 27, 2023 18:31
Co-authored-by: Simon Dowdles <72872375+10upsimon@users.noreply.github.com>
Co-authored-by: Simon Dowdles <72872375+10upsimon@users.noreply.github.com>
Co-authored-by: Simon Dowdles <72872375+10upsimon@users.noreply.github.com>
Co-authored-by: Simon Dowdles <72872375+10upsimon@users.noreply.github.com>
Copy link
Collaborator

@joemcgill joemcgill left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The updates are looking good. I left a couple new questions and will do a final review once we have the tests from #14 merged back here so we can ensure everything is covered.

* Get the strategy mentioned during script registration.
*
* @param string $handle The script handle.
* @return string|bool Strategy in script registration, False if not strategy is mentioned..
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* @return string|bool Strategy in script registration, False if not strategy is mentioned..
* @return string|bool Strategy in script registration, False if not strategy is mentioned.

src/wp-includes/class-wp-scripts.php Show resolved Hide resolved
tests/phpunit/tests/dependencies/scripts.php Outdated Show resolved Hide resolved
* blocking if explicitly set.
* blocking if script args not set.
*/
if ( ! isset( $this->registered[ $handle ] ) || 'blocking' === $intended_strategy || ! $intended_strategy ) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still confused about why script registration is being checked here after the intended strategy instead of before? Can you explain the use case for me?

I'd also suggest splitting this back to multiple lines for readability, just make sure the operators are at the beginning of each line, like the previous suggestion.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are correct. script registration should be above getting intended script. I have made the change.

Now that the condition have become much smaller I have kept it on the same line.

@10upsimon
Copy link

@joemcgill in case you missed it, noting that the PR at #34 was merged into the same base branch this is going to 👍

src/wp-includes/class-wp-scripts.php Outdated Show resolved Hide resolved
* @param string $handle The script handle.
* @return array Array of script handles.
*/
private function get_dependents( $handle ) {
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: This needs to be optimised further. Better way of doing this is creating a dependents list as a hash table (added as a Dependencies to WP_Script) and updated dependents while each script is getting registered. get_dependent will simply fetch dependent from that hash table.

src/wp-includes/class-wp-scripts.php Outdated Show resolved Hide resolved
}

// Handling async strategy scenarios.
if ( empty( $this->registered[ $handle ]->deps ) && empty( $this->get_dependents( $handle ) ) ) {
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@joemcgill Test cases are the main reason I had to set a base milestone branch. The way our milestone tasks are, we normally have to get to the last task to test out all the other prior tasks in the milestone.

In milestone 2, get_eligible_strategy can only be tested via do_item method ( #38 ) which is a part of different task in same milestone. In milestone 2 all test cases are in PR #38.

Just to be certain that everything in a single milestone works as intended before it goes to the base branch, i created a separate milestone base branch.

return 'async';
}

// Handling defer strategy scenarios. Dependency will never be set async. So only checking dependent.
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@10upsimon So, per the rules, defer can only have 'defer' or 'blocking' dependencies; it can never be 'async'. ( point 1 )

A decision that a script is to be set to async, defer, or nothing is made by get_eligible_loading_strategy.

But, if you check the rules for async in this function, a script with dependent will never be set async. ( point 2 ).

From points 1 and 2, I can say if the current script has some dependency, the dependency script will never have async strategy (as it has a dependent). So we can avoid a recursion check to find strategy in dependencies.

I hope I still don't sound confusing.

src/wp-includes/class-wp-scripts.php Show resolved Hide resolved
* blocking if explicitly set.
* blocking if script args not set.
*/
if ( ! isset( $this->registered[ $handle ] ) || 'blocking' === $intended_strategy || ! $intended_strategy ) {
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are correct. script registration should be above getting intended script. I have made the change.

Now that the condition have become much smaller I have kept it on the same line.

return 'async';
}

// Handling defer strategy scenarios. Dependency will never be set async. So only checking dependent.
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@10upsimon I have removed the extra text here.

tests/phpunit/tests/dependencies/scripts.php Outdated Show resolved Hide resolved
src/wp-includes/class-wp-scripts.php Show resolved Hide resolved
Copy link
Collaborator

@joemcgill joemcgill left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is looking good now 👍🏻

kt-12 and others added 2 commits February 28, 2023 18:39
Script Loading Strategy - ML2 #14 - Update `do_item` method.
@kt-12 kt-12 requested a review from 10upsimon February 28, 2023 18:41
@kt-12 kt-12 merged commit 16c4634 into enhancement/wp-script-api-strategy-base Mar 1, 2023
@kt-12 kt-12 deleted the enhancement/get_eligible_loading_strategy-ML2-12 branch March 1, 2023 14:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs:code-review This requires code review.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Addition of get_eligible_loading_strategy() method to surface correct strategy for a given script handle
3 participants